The invention relates to a method for traffic engineering on networks made of asymmetrical network switches and to an asymmetrical network switch adapted to auto-discover and advertise into a traffic engineering, TE, domain a switch detailed connectivity matrix, SDCM.
Conventional packet switched networks such as IP/MPLS networks can be considered with a sufficient accuracy as made of non-blocking symmetrical switches. A non-blocking switch can be defined as one that can relay data incoming into the switch over one of its interfaces, i.e. an input interface, on to any other interface, i.e. output interface that belongs to the same layer network as the input interface. A blocking switch can be defined as one that can switch data from a given input interface on to a subset but not all same layer network output interfaces. From the point of view of a data flow traversing a switch towards the data destination, there are no disallowed input/output interface combinations in case of a non-blocking switch and there are such combinations in case of a blocking switch. In a network as depicted in FIG. 1 the shown switch S can be considered as a non-blocking switch if data incoming into the switch over one of its interfaces S1 to S8 can be switched on to any other of its interfaces.
A symmetrical switch can be defined as one that can switch data between a (unicast)pair/(multicast)set of interfaces with equal treatment, characteristics, quality of service and visible by the user effect on the data as between any other pair/set of interfaces. In other words, switching data by a symmetrical switch exhibits identical cost, data delay and lost characteristics, optical signal impairments, etc. regardless of which of its interfaces participate in the switching. On the contrary, switching on an asymmetrical switch causes different effects on the cost and quality of service of the data transfer depending on which pair of interfaces (in case of unicast) or a set of interfaces (in case of multicast) is selected for switching the data flow in question. For example, switch S shown in FIG. 1 can be considered as a symmetrical switch, if a data flow switched, for instance, over the switch interface pair S1, S2 experiences the exact same treatment as when switching over the interface pair S1, S5 or any other pair of interfaces of switch S.
The problem of routing on a network made of blocking switches was addressed in IETF CCAMP working group “General Network Element Constraint Encoding for GMPLS Controlled Networks” 83rd IETF Paris, France, March 2012. It was suggested to advertise a connectivity matrix for the purpose of path selection on the networks with at least one blocking switch. A connectivity matrix is advertised into a TE domain comprising at least one blocking switch by each of the blocking switches. The connectivity matrix provides information for the network path computer to select switchable combinations of input/output interfaces for every network switch that appears in the resulting paths.
Although the suggested solution is sufficient to address a blocking switch problem, it is not sufficient for handling asymmetrical switches.
The first reason is that there is a potential inaccuracy and sub-optimality of selected paths. For instance, if there are two pairs of switchable interface groups on a network switch, such as switch S, shown in FIG. 1, interfaces S3, S8 (group 1) and S4, S7 (group 2) and one of the groups, e.g. group 1 causes a data delay of x milliseconds, while the other group causes a data delay of y milliseconds (where x<y), because the delay values, x and y, of the data delay are not advertised, they are not available to a network path computer. Consequently, it is quite possible that the interface combination S4, S7 with the higher data delay is selected for the resulting path, while the interface pair S4, S7 having a lower data delay is not selected. Generally speaking, when a switching metric of a certain type, which for the same switch varies from one switching pair/set to another, is not advertised, the path computer with respect to the switch in question has to assume a worst case scenario which inevitably yields inaccurate and suboptimal results.
The second reason is the inability to compute equipment disjoint paths going through the same switch. Equipment disjoint paths are needed for the purpose of service protection against network failures. When two or more interfaces are cross-connected, this means that they are interconnected via an internal path that involves devices and appliances internal to the respective switch. The internal paths within the switch may use non-overlapping or overlapping sets of internal devices/appliances. To illustrate this, the exemplary switch S shown in FIG. 1 is depicted with internal devices labelled I-SRLG1 to I-SRLG5. For example, internal paths within the switch S supporting switching interface combinations S3S8 and S4S7 can use non-overlapping or overlapping sets of internal devices. Non-overlapping sets of internal devices for the interface switching combinations S3 S8 and S4S7 are [I-SRLG1, I-SRLG3] and [I-SRLG4, I-SRLG5], respectively. Overlapping sets of internal devices are, for instance, [I-SRLG1, I-SRLG3] and [I-SRLG4, I-SRLG3, I-SRLG5], respectively. In the case of non-overlapping network internal devices, the paths are equipment disjoint, whereas in the case of overlapping sets of internal devices, the paths are not equipment disjoint. Because the information about the internal devices is not advertised into the TE domain, the network path computer does not have a visibility as to how the resulting paths will be provisioned internally on selected for the paths switches. Specifically, if two or more paths are selected to go through the same network switch, the path computer has no way of knowing whether the paths will use the same or different devices inside the respective network switch. For example, the network path computer does not know whether the internal device labelled as I-SRLG3 will or will not be used on switch S when two paths (one path using S3S8 interface combination and the other path using S4S7 interface combination) are provisioned. Consequently, the path computer does not know whether it is possible or not for a failure of one of these internal devices (e.g. I-SRLG3) to yield two or more of said paths simultaneously inoperable. Therefore, in order to guarantee path equipment diversity in conventional systems, path computers have to select switch-disjoint paths, i.e. paths that have no transit switches in common. This is suboptimal and insufficient, because switch-disjoint paths may not exist or be suboptimal to equipment disjoint paths converging on some switches. Furthermore, switch-disjoint paths selected for a given service share switches on the service source and destination, hence they do not protect against failures that may happen inside the service termination switches, while equipment disjoint paths protect services even in this case.
The third reason as to why the conventional solution is not sufficient for handling asymmetrical network switches resides in the inefficient routing of a service away from a failed network switch. If, for instance, a failure is detected on a switch internal device such as the entity identified as I-SRLG3 within the network switch S depicted in FIG. 1, the service of a conventional system can only be routed away from the entire network switch, but not within the switch away from the failed internal device. For example, if the S3S8 switching combination uses internal path supported by device identified as I-SRLG3, by selecting an alternative internal path (for instance, supported by devices identified as I-SRLG1, I-SRLG2) for the S3 S8 switching combination, or by selecting an alternative switching pair, for example, S4S7 that uses the internal path supported by internal devices labelled as I-SRLG4, I-SRLG5, one could route the service away from the internal device I-SRLG3 in case it fails within the switch S. However, this is not possible in a conventional path computation environment because switch internal devices are not known in any form to the network path computers.
Accordingly, there is a need for a method and system which overcome the above-mentioned drawbacks and which allow also for the efficient handling of asymmetrical network switches.